1. Field of the Invention
The present invention relates to an information processing apparatus and a print setting reflection method pertaining to an information processing apparatus, which may include, but is not limited to, for example, print processing using a plurality of varying graphics engines.
2. Description of the Related Art
It is typical for an operating system to take on a configuration such as that depicted in FIG. 3, in order to print an image or a text on a print apparatus from an application that is being executed on a host computer. An application 101 passes a graphics data to a graphics engine 103 by calling a drawing function provided by the graphics engine, and the graphics data is processed in the graphics engine 103 and passed to a printer driver 104, which generates a print data for the print apparatus, typically in Page Description Language, or PDL. After the print data is stored in a spooler 105, it is sent to a print apparatus 1500.
The graphics engine 103 performs processing of the image data such as converting a resolution of the print data that is created in the application 101, or simulation processing in line with the printer driver's 104 capability. It is thus possible for the application 101 and the printer driver 104 to run independently of one another. The graphics engine 103 is normally provided as a component of an operating system 102.
The graphics engine 103 is not necessarily limited to one engine. It is also possible to have an operating system wherein two or more graphics engines coexist.
For example, WinHEC 2005, a hardware engineering conference, was sponsored in 2005 in Seattle, Wash. by Microsoft. A new Microsoft operating system, with the name of Windows® Vista, was introduced at WinHEC 2005, as having a configuration with two coexisting graphics engines, as depicted in FIG. 1. As of Feb. 28, 2005, refer to Advances in Windows Printing: TWPR05001_WinHEC05.ppt, May 7, 2004, at Microsoft.com®, on the Architecture and Driver Support for Printer Technology for Windows Printing Technologies page.
A conventional Microsoft printing system uses a graphics engine called Graphic Device Interface (GDI), via an application that uses an application programming interface, or API, known as a Win32 API, i.e., a Win32 application. The print data is created from the graphics data, via the printer driver that is called from the GDI, i.e., a GDI printer driver. The print processing route is referred to according to the embodiment as a GDI print path.
In Windows Vista, a new print path, known as an XPS print path, is added to the existing GDI print path. With the XPS print path, a graphics engine known as Windows Presentation Foundation (WPF) is provided by the operating system, via an application that uses an API known as a WinFx API, i.e., a WinFX application. A graphic data in XML Paper Specification (XPF) format is passed by the WPF graphics engine to the printer driver, i.e., an XPS printer driver, which converts the graphic data to the printer data.
The GDI and WPF graphics engines can link together. Such a link facilitates passing the graphics data from a Win32 application to an XPS printer driver, as well as passing the graphics data from a WinFX application to a GDI printer driver.
Because of the link, when a print is performed from the WinFX application using the GDI printer driver, the graphics data is converted in the WPF graphics engine to a graphics data in the XPS format, which in turn is converted to a graphics data in an EMF format. After the converted graphics data is stored in an EMF spool file, a conversion to the print data is performed in the GDI driver.
When a print is performed from the Win32 application using the XPS printer driver, the graphics data is converted in the GDI graphics engine to a graphics data in the EMF format, which in turn is converted to a graphics data in the XPS format. After the converted graphics data is stored in an XPL spool file, a conversion to the print data is performed in the XPS driver.
Thus, four print paths are offered within Windows Vista. Offering either a GDI printer driver or an XPS printer driver thus allows support for print processing from both a Win32 application and a WinFx application.
Differences between the XPS format and the EMF format, however, lead to issues with graphics data format conversion in areas that include, but are not limited to, print quality, feature set, or print speed.
For example, a graphics data that contains a logical operation such as a raster operation process (ROP) computation, which is supported in the EMF format, would not be supported in the XPS format. Thus, under a specification established by Microsoft, converting the graphics data that contains the logical computation with a GDI-XPS conversion module that converts from the EMF format to the XPS format runs a risk of having the logical computation information being stripped out. It is possible that, when the graphics data from which the logical computation information has been removed is passed to the XPS printer driver, it may not be possible for an output result intended in the Win32 application to be created by the XPS printer driver.
Conversely, a sophisticated graphics data that is supported in the XPS format is not supported in the EMF format. Consequently, when converting such a graphics data from the XPS format to the EMF format with an XPS-GDI conversion module, a local bitmapping, known as flattering, is performed. In such a circumstance, the conversion of the graphics data into a bitmap data means that no determination can be made of original object properties on the part of the GDI printer driver, which, thus, cannot create an output result that corresponds to the object properties. Data format conversion degrades outputted image quality. For example, when performing an n page print with the printer driver, the bitmapped data is compressed and positioned, and thus, image quality is lower than when drawing a graphics object at a reduced size.
For example, electronic signature information that is supported in the XPS format is not supported in the EMF format. A process of directly giving information from an application to the GDI printer driver, which is supported in the EMF format, is not supported in the XPS format. Thus, when converting from the XPS format to the EMF format, or conversely, in the opposite direction, if an instruction is included in the pre-conversion format graphic data that uses a feature that is not supported in the post-conversion format, the feature will not be carried out. When a data format conversion process is performed, a feature that cannot be fulfilled may be present within the graphics data of the respective formats.
An occurrence of a process, including but not limited to GDI-XPS conversion, or XPS-GDI conversion, also gives rise to a process overhead, which runs a risk of print processing speed being slower than a path that does not require a conversion.
Hence, when a data format conversion is performed, a problem occurs also with any of a quality aspect, a feature set aspect, or a speed aspect. Accordingly, it is desirable to avoid a print path wherein the data format conversion is performed.
At the same time, a selection of a printer driver to use is left to a user, even when the XPS printer driver and the GDI printer driver are installed in a computer for a common print apparatus. The graphics engine in Windows Vista does not automatically perform a selection of a path that does not require a data format conversion. Many typical users are not conscious of whether an application is a Win32 application or a WinFX application, nor are they aware that there are four print paths. Thus, once a user selects a printer driver as a default printer driver, the selected printer driver will be used regardless of the type of application. In such manner, it has been difficult, if not impossible, to avoid a data format conversion in the print path, of the GDI-XPS conversion or the XPS-GDI conversion.